The following table describes the third-party SSH and SCP client software that has been tested but is not included with the switch software.
SSH Client |
Secure Shell (SSH) |
Secure Copy (SCP) |
---|---|---|
Tera Term Pro with TTSSH extension MS Windows |
|
|
Secure Shell Client Windows 2000 |
|
|
OpenSSH Unix Solaris 2.5 / 2.6 |
|
|
WinSCP |
This SCP client is unsupported on the switch. |
The switch acting as the SSHv2 client generates a DSA public and private server key pair. The public part of the key for DSA is stored in the following location:
/intflash/.ssh/dsa_key_rwa
Note
For certain switches in enhanced secure mode, all sensitive files are protected. The home directory for protected files is /intflash/shared. You cannot access any sensitive files using Telnet, SSH, FTP, SFTP, TFTP, and SCP connections. For more information, see Sensitive File Protection.
The public part of the key must be copied to the SSH server and be named according to the naming requirement of the server.
Consult DSA Authentication Access Level and File Name for proper naming convention.
If a DSA key pair does not exist, you can generate the DSA key pair using the ssh dsa-user-key [WORD<1–15>] [size <1024-1024>] command.
You need to copy the DSA public key to the SSHv2 server that you connect to using the switch as a client. RSA is not supported when using the switch as a client, but you can use RSA when the switch is acting as the server.
Note
SSH RSA and DSA public and private keys are copied from /intflash/shared to /intflash/.ssh.
After you install one of the SSHv2 clients you must generate a client and server key using the RSA or DSA algorithms.
To authenticate an SSHv2 client using DSA, the administrator must copy the public part of the client DSA key to /intflash/.ssh directory on the switch that acts as the SSHv2 server. The file that is copied over to the SSHv2 server must be named according to DSA Authentication Access Level and File Name.